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Abstract 

The  commonly  recognized  benefits  of  software  reuse  are  increased  productivity,  higher 
quality,  shorter  time-to-market,  and  reduced  development  and  maintenance  costs.  Software 
reuse  is  a  key  thrust  of  DoD  acquisition  improvement  initiatives  including  the  Naval  Open 
Architecture  program.  Successful  reuse  depends  on  many  aspects  of  a  reuse  program,  ranging 
from  organizational  climate  to  technical  solutions.  As  technical  solutions,  current  software 
repositories  do  not  provide  robust  search  and  discovery  capabilities  due  to  limitations  of  current 
information  organization  practices. 

This  research  explores  potential  solutions  that  are  enabled  when  ontologies  are  used  as 
the  framework  for  information  contained  in  the  software  repository.  In  this  paper,  we  will  briefly 
summarize  previous  work  on  an  ontology-based  repository  framework.  We  will  then  present 
current  efforts  to  specify  a  software  repository  tool  that  exploits  the  framework  to  enable  more 
sophisticated  search  and  discovery. 

The  suggested  tool  will  emphasize  human  interaction  and  allow  users  to  bring  their 
context  to  the  search  process.  New  navigation  techniques  will  be  employed  that  guide  human 
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users,  offering  suggestions  based  on  projected  needs.  The  improved  search  capability  will 
encourage  developers  to  consider  reuse  and  aid  in  its  success. 

Introduction 

In  August  2006,  Program  Executive  Officer  of  Integrated  Warfare  Systems  (PEO-IWS) 
established  the  Software  Hardware  Asset  Reuse  Enterprise  (SHARE)  repository  to  enable  the 
reuse  of  combat  system  software  and  related  assets.  In  July  2007,  the  Naval  Postgraduate 
School  (NPS)  was  tasked  to  develop  a  component  specification  and  ontology  for  the  SHARE 
repository. 

A  description  of  SHARE  and  the  requirements  for  a  component  specification  and 
ontology  supporting  this  repository  are  available  in  Johnson  (2008).  A  vision  of  the  component 
specification  and  ontology  for  the  repository  framework,  a  brief  survey  of  initiatives  and 
technologies  relevant  to  desired  repository  capabilities,  a  development  approach,  and  initial 
design  are  described  in  Johnson  and  Blais  (2008,  March).  In  Johnson  and  Blais  (2008, 
September)  we  provided  the  initial  component  specification  and  ontology  for  the  repository 
framework,  as  well  as  initial  information  models  supporting  future  implementation  of  stronger 
semantic  representations  of  assets  and  artifacts  in  the  repository. 

This  paper  and  presentation  summarize  the  previous  work  and  discuss  the  current 
research  being  conducted,  which  will  result  in  a  requirements  specification  for  improved 
software  repository  tools. 

Repository  Framework 

In  Johnson  and  Blais  (2008,  March),  we  proposed  a  repository  framework  for  SHARE, 
consisting  of  two  major  aspects:  a  component  specification  and  ontology.  The  component 
specification  is  a  description  or  model  of  the  items  in  the  repository  and  consists  of  two  parts: 
metadata  and  software  behavior  representation.  The  ontology  describes  concepts  and 
relationships  to  create  various  perspectives  or  contexts  for  examining  the  contents  of  the 
repository.  These  aspects  of  the  framework  are  discussed  below. 

1.  Component  Specification:  Metadata 

The  metadata  for  each  artifact  should  incorporate  all  necessary  data  for  discovery  and 
implementation.  The  metadata  will  aid  repository  users  in  determining  if  the  item  is  suited  for 
their  use  and  will  provide  information  about  how  to  use  the  asset  when  it  is  retrieved.  We  refer 
to  this  as  “standard”  or  “typical”  metadata  since  there  are  many  existing  examples  of  metadata 
we  can  use  to  develop  the  metadata  for  SHARE. 

We  developed  a  metadata  schema  for  the  SHARE  repository  and  presented  its  details  in 
Johnson  and  Blais  (2008,  September).  An  initial  list  of  required  asset  information  developed  by 
the  SHARE  Program  Office  at  Naval  Surface  Warfare  Center,  Dahlgren,  VA,  was  used  as  a 
starting  point.  We  began  by  creating  an  Extensible  Markup  Language  (XML)  Schema  for  this 
metadata  set  and  then  enhanced  the  schema  based  on  a  more  current  “wizard”  that  leads  a 
user  through  the  SHARE  asset  information  entry  process. 

After  careful  analysis  of  this  initial  schema,  as  well  as  known  metadata  examples  found 
in  existing  software  repositories,  we  began  to  modify  the  schema  by  reorganizing  the  data  and 
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complementing  the  fields  with  information  that  should  be  included.  We  also  incorporated  the 
necessary  information  to  place  each  artifact  in  the  appropriate  context  based  on  the  ontology 
development.  Finally,  we  evaluated  the  schema  against  the  minimum  requirements  of  the  DoD 
Discovery  Metadata  Specification  (Deputy  Assistant  Secretary  of  Defense,  2007)  to  promote 
future  exposure  of  SHARE  contents  across  the  DoD  Enterprise. 

The  most  significant  recommended  change  to  the  current  SHARE  approach  to  handling 
metadata  is  the  level  of  application.  It  is  our  assertion  that  to  enable  the  satisfaction  of 
repository  user  needs,  metadata  must  be  applied  at  the  artifact  level  rather  than  at  the  asset 
level,  which  is  the  current  methodology  for  SHARE. 

To  be  clear,  we  must  provide  our  definition  of  these  two  concepts.  The  Navy  Open 
Architecture  (OA)  program  has  adopted  similar  definitions  for  asset  and  artifact  as  those  used  in 
the  Object  Management  Group  (OMG)  Reusable  Asset  Specification  (RAS).  In  the  RAS, 
artifacts  are  defined  as  “any  work  products  from  the  software  development  lifecycle,”  and  assets 
are  a  grouping  of  artifacts  that  “provide  a  solution  to  a  problem  for  a  given  context”  (Object 
Management  Group,  2005,  p.  7).  Accordingly,  the  RAS  describes  an  approach  for  packaging 
artifacts  into  an  asset. 

This  is  consistent  with  the  current  SHARE  approach  and  remains  consistent  in  the 
proposed  metadata  schema.  However,  the  current  SHARE  approach  is  to  package  artifacts  into 
assets  at  the  convenience  of  the  submitter  and  to  enable  the  current  retrieval  process.  We 
believe  it  is  more  useful  to  enable  packaging  of  artifacts  into  assets  based  on  users’  needs.  This 
means  that  the  grouping  of  artifacts  into  an  asset  should  have  the  capability  of  being  user- 
defined.  In  order  to  enable  this  approach,  the  users  must  be  able  to  discover  the  artifacts  of 
potential  value  to  their  particular  context  in  order  to  solve  a  particular  problem  and  then  package 
those  artifacts  into  an  asset  for  retrieval. 

Therefore,  the  proposed  metadata  schema  includes  separate  definitions  of  structures  for 
artifacts  and  assets.  This  does  not  preclude  the  pre-packaging  of  artifacts  into  assets  for 
submission  to  the  repository  or  for  extraction  to  solve  common  problems.  We  envision  the 
capability  for  users  to  discover  a  problem  solution  by  either  locating  a  prepackaged  (reusable) 
asset  or  by  building  an  asset  from  artifacts  they  believe  will  help  solve  their  particular  problem. 

Splitting  the  metadata  into  two  schemas,  one  for  assets  and  another  for  artifacts,  also 
enables  a  clearer  distinction  about  the  data  that  needs  to  be  collected  for  each.  For  example, 
the  current  SHARE  metadata  collects  data  on  the  type  of  artifacts  included  in  the  asset,  such  as 
whether  they  are  documents  or  code.  Then,  it  separately  asks  for  thousands  of  lines  of  code 
(KSLOC)  for  the  asset.  This  would  more  likely  be  tied  to  particular  artifacts  that  are  of  the  type 
“code”  in  the  asset.  By  separating  the  asset  and  artifact  schemas,  we  can  better  distinguish  the 
necessary  data  for  an  asset  from  the  necessary  data  for  an  artifact,  and  we  will  be  able  to 
manipulate  the  data  more  appropriately  with  tools  that  implement  the  search. 

Collecting  metadata  information  for  each  artifact  may  seem  like  a  daunting  task  when 
compared  to  the  current  method.  However,  it  is  highly  likely  that  a  good  portion  of  the  metadata 
that  applies  to  one  artifact  also  applies  to  the  remaining  artifacts  in  a  group  of  submitted 
artifacts.  The  submission  tool  can  be  constructed  to  minimize  duplicative  entries  of  data  by 
prompting  users  to  verify  that  the  information  being  entered  applies  to  all  the  artifacts  in  a  group. 
This  construction  would  minimize  the  individual  entries  required  in  the  submission  and  metadata 
collection  process.  It  is  also  possible  to  create  tools  that  automate  much  of  the  metadata 
collection  from  the  artifacts  themselves.  Other  organizations  are  conducting  research  and 
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development  to  auto-generate  metadata  from  the  source  products.  This  is  a  critical  capability  in 
making  legacy  content  available  for  search  and  discovery.  Adoption  of  structured  metadata 
makes  autogeneration  feasible,  although  certainly  nontrivial.  This  is  a  recommended  area  for 
future  research  and  development  in  the  SHARE  program. 

Artifact  Schema 

The  artifacts  schema  is  designed  to  be  flexible  in  its  implementation.  All  the  elements, 
types  and  attributes  in  the  schema  are  defined  globally  so  they  can  be  reused  in  other  schemas 
that  developers  may  create  for  working  with  artifact  information.  The  root  element,  Artifacts,  is 
simply  a  container  for  any  number  of  artifacts  contained  in  a  single  instance  of  the  schema,  as 
shown  in  Figure  1.  Repository  managers  and  tool  designers  can  decide  if  they  wish  to  keep  a 
separate  XML  file  describing  each  artifact  or  if  they  prefer  to  group  multiple  artifact  descriptions 
into  a  single  XML  file. 


1 - 

- i 

Artifact  slype 

Artifacts  - 1-(  •••  jEl~ 

^Artifact  [+] 

Arcfacts  is  the  root  dement  i 

1..X 

for  indi vidua!  art-acts. 

Individual  artifacts.  Can 

T v'tv*  !  A  rtif 3CT?T vp^ 

1 

i_ 

location  or  URL.  Type:  i 

Figure  1.  Artifacts  Element 


The  individual  descriptions  of  each  artifact  are  also  designed  to  be  flexible.  A  specific 
artifact  can  be  incorporated  into  the  file  in  one  of  three  ways.  The  first  is  by  providing  the  full 
artifact  description.  This  full  description  represents  the  heart  of  the  metadata  development  effort 
and  should  be  considered  the  preferred  method  for  representing  an  artifact.  However,  if  the  full 
description  is  not  available,  or  if  the  information  required  is  provided  in  some  other  location,  the 
schema  allows  the  inclusion  of  the  artifact  representation  by  reference — either  to  a  physical 
location  or  by  URL.  This  is  shown  in  Figure  2. 

The  full  description  of  each  artifact,  contained  in  the  element  ArtifactFullDescription,  is 
composed  of  eight  sub-elements  as  depicted  in  Figure  3.  Each  sub-element  is  discussed  in 
detail  in  Johnson  and  Blais  (2008,  September). 


DEFENSE  ACQUISITION  IN  TRANSITION 


-80- 


ArtifactType 


I 


Individual  artifacts.  Can 


either  be  a  fill  description,  or 
a  reference  by  physical 
location  or  URL.  Type: 
ArtifactType 


^  ArtifactFullDescription  |+| 

The  recommended  fuB  description 
of  an  artifact.  Type: 
ArofactFuItType 


jArtifactPhysicalReference 


A  physical  reference  to  an  artifact. 

T ype :  A  rtif actPhysca  IReferenceT  ype 


f  A  rtifactU  RL  Refe  rence 


A  URL  reference  to  an  artifact. 
Type: 

ArtifactU  RLReferenceT  ype 


Figure  2.  Artifact  Element 
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Figure  3.  Artifact  Full  Description  Element 

Asset  Schema 

In  the  preceding  description  of  artifacts,  we  see  that  much  of  the  detail  about  a 
submission  has  been  moved  to  the  artifact  level.  The  information  needed  to  describe  an  asset  is 
thus  simplified  to  be  primarily  an  identification  of  the  artifacts  contained  in  the  asset.  The  root 
element  of  the  assets  XML  structure  is  a  container  for  one  or  more  asset  records,  as  shown  in 
Figure  4.  The  proposed  top-level  XML  structure  for  an  asset  is  shown  in  Figure  5. 
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Figure  4.  Assets  Root  Element 
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Figure  5.  Asset  Element 

The  remaining  sub-elements  of  the  asset  schema  are  described  in  Johnson  and  Blais 
(2008,  September). 

2.  Component  Specification:  Software  Behavior 

The  metadata  for  many  current  repositories  fail  to  capture  a  searchable  representation  of 
the  behavior  of  the  items  outside  general  categories  of  functionality  (e.g.,  Archiving 
Compression  Conversion,  Control  Flow  Utilities,  Graphics,  and  Security)  and  text-based  search 
of  code  descriptions.  Unlike  current  practice,  the  SHARE  component  specification  will  consist  of 
both  typical  metadata  and  a  behavioral  model  of  the  component.  Since  this  piece  of  the 
component  specification  is  not  commonly  incorporated  into  repositories  in  a  standardized 
manner,  we  feel  it  is  a  specific  focus  area  to  identify  the  appropriate  representation  mechanisms 
for  software  behavior  in  the  repository  context. 
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One  of  the  loftier  goals  of  a  software  repository  is  to  support  automatic  composition  of 
systems  from  reusable  components.  This  is  a  difficult  problem,  which  many  have  tried  to  solve.1 
It  is  especially  difficult  if  the  components  were  not  originally  designed  for  reuse.  As  a  necessary 
first  step  towards  more  sophisticated  uses  of  a  repository,  behavioral  descriptions  must  be 
machine-readable  in  order  to  support  automated  search  and  discovery.  Furthermore,  the 
behavior  descriptions  must  be  formalized  and  consistently  applied  to  each  item  in  the  repository 
if  the  intent  is  to  automatically  compose  them  into  a  larger  functioning  system. 

In  our  efforts  towards  standardized  specification  of  software  behavior  for  the  SHARE 
repository,  we  have  sought  a  balance  between  method  robustness  and  ease  of  implementation. 
Each  type  of  presented  representation  offers  advantages  for  certain  purposes.  However,  it  is 
recognized  that  the  array  of  contributors  to  SHARE  requires  caution  in  dictating  standards  that 
will  impact  the  development  processes  of  the  asset  developers. 

We  explored  characterization  of  software  interfaces  based  on  current  and  emerging  Web 
Services  (e.g.,  WSDL)  and  Semantic  Web  Services  (e.g.,  WS-BPEL,  OWL-S)  approaches. 
However,  the  work  is  preliminary,  since  the  current  approach  to  describing  code  artifacts  making 
up  an  asset  is  extremely  limited.  It  will  be  necessary  to  adopt  a  more  precise  description  of  code 
artifacts  to  introduce  these  techniques.  As  a  start,  we  included  the  option  of  inserting  a  WSDL 
description  of  software  services  in  the  SoftwareBehaviorDescription  element. 

We  also  proposed  a  near-term  solution  that  uses  domain  information  to  standardize 
descriptions  of  software  functionality;  namely,  the  well-established  Common  System  Function 
List  (CSFL).2  We  developed  a  taxonomy  based  on  the  CSFL  and  incorporated  fields  into  the 
metadata  (XML  schema)  that  will  assign  functions  to  repository  items.  If  we  require  asset 
submitters  to  state  the  functionality  of  the  components  in  these  terms,  we  can  then  build  the 
tools  to  guide  users  in  selecting  desired  behavior  in  the  same  terms. 

The  CSFL  was  captured  in  an  OWL  structure  to  use  as  an  initial  characterization  of 
software  behavior.  The  process  by  which  the  taxonomy  was  generated  is  a  good  example  of 
methods  for  creating  a  practical  set  of  structured  data  from  initial  raw  formats.  The  taxonomy 
was  constructed  from  a  Microsoft  Excel  spreadsheet  (CSFL  version  3.0).  The  spreadsheet 
provided  definitions  of  the  domains  and  functions,  identified  what  the  domain  or  function  is 
derived  from  and  identified  sources  of  the  definitions.  Microsoft  Excel  provides  the  capability  to 
export  the  content  of  the  spreadsheet  to  XML  format.  A  simple  Extensible  Stylesheet  Language 
for  Transformations  (XSLT)  was  written  to  transform  the  source  XML  format  (spreadsheet  data) 
to  a  target  XML  format  (OWL).  The  transformation  created  a  simple  class/subclass  hierarchy 
expressed  in  OWL.  A  portion  of  the  resulting  OWL  structure  is  shown  in  the  Protege  ontology 
editing  tool  in  Figure  6. 


1  The  proceedings  from  the  International  Symposium  on  Software  Composition,  an  annual  event,  provide 
examples  of  research  into  the  breadth  of  research  topics  currently  being  pursued  in  the  area  of  software 
composition.  The  website  for  the  2008  conference  is  located  at  http://www.2008.software- 
composition.org/ 

2  DoD  Warfighter  Service  Components  in  the  DoD  Enterprise  Architecture  Service  Component  Reference 
Model  are  derived  from  the  DoN  CSFL. 
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Figure  6.  Portion  of  the  CSFL  Taxonomy  Displayed  in  Protege 
under  the  Jambalaya  Graphics  Tab 

Other  similar  lists  have  been  developed  for  operational  activities  (i.e.,  the  Common 
Operational  Activities  List  (COAL))  and  for  information  elements  (Common  Information  Element 
List  (CIEL)).  It  may  be  valuable  to  also  capture  these  in  OWL  classes  and  then  create 
interrelationships  across  the  classes  (e.g.,  what  information  elements  are  generally  employed  in 
performing  certain  system  functions  and  what  information  elements  are  generally  produced  by 
performing  certain  system  functions,  etc.).  Further  exploration  with  subject-matter  experts  is 
needed  to  determine  potential  benefit  from  such  approaches. 


Although  we  cannot  solve  the  software  composition  problem  in  the  near-term,  initial 
descriptions  of  software  behavior  through  identification  of  functionality  and  specification  of 
interfaces  are  necessary  steps  toward  that  capability.  These  intermediate  steps  toward 
formalized  behavior  descriptions  will  prove  useful  in  the  near-term  and  helpful  in  advancing 
long-term  goals. 


3.  Ontology  of  Framework  Relationships 

The  framework  ontology  includes  descriptions  of  the  component  relationships  to  form  a 
contextual  model  of  the  repository  items.3  These  relationships  may  include  the  component’s 
use/role  in  existing  systems,  its  mapping  to  reference  or  domain  architectures,  and  its  utility  in 
various  software  development  lifecycle  phases.  Contextual  information  about  the  artifact  can  be 


3  Throughout  the  document,  ontology  is  used  as  a  general  term  for  describing  concepts  and  relationships 
among  concepts,  with  taxonomy  as  a  special  case  in  which  the  classes  in  the  ontology  are  related  by  a 
single  property,  such  as  “is-a”  or  “has-a.” 
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exploited  to  enable  sophisticated  search  and  discovery  methods  that  more  closely  match 
recommended  retrieval  items  to  a  user’s  problem  context. 

Assets  and  artifacts  in  the  SHARE  repository  can  be  examined  from  a  number  of 
perspectives,  reflecting  a  variety  of  associations.  We  chose  to  create  initial  classification 
schemes  that  can  provide  benefit  in  the  near-term.  The  resulting  taxonomies  and  ontologies  are 
meant  to  be  illustrative,  not  exhaustive.  The  taxonomies/ontologies  we  developed  for  SHARE 
are  based  on  several  types  of  relationships  between  the  items  in  the  repository,  as  well  as  with 
relevant  domain  architectural  descriptions  and  other  information.  They  capture  an  artifact’s 
place  in  the  software  engineering  lifecycle  (see  Figure  7),  its  architectural  fit  in  its  original 
system  (see  Figure  8),  its  architectural  fit  in  any  system  in  which  it  was  subsequently  used, 
identification  of  the  component’s  fit  in  the  Surface  Navy  Objective  Architecture  (see  Figure  9), 
and  the  semantic  relationships  of  various  documents  in  the  repository.  Each  of  these  ontologies 
is  discussed  in  detail  in  Johnson  and  Blais  (2008,  September). 

This  enriched  semantic  specification  of  the  assets  in  the  SHARE  repository  will  enable 
users  to  more  readily  find  resources  that  meet  their  needs  in  their  context.  Extensive  work  in  the 
Web  community  is  providing  tools  and  techniques  that  can  be  applied  to  the  framework  when  it 
is  based  on  these  ontologies.  We  have  created  an  initial  semantic  foundation  on  which 
enhanced  capabilities  can  be  implemented. 
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Figure  8.  System  Ontology  Example  (AEGIS) 
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Figure  9.  Surface  Combat  System  Top-level  Objective  Architecture  Described  as  a 
Taxonomy  in  OWL  (Jambalaya  Graphic  Tab  in  Protege) 

Current  Research 

Current  research  efforts  focus  on  designing  repository  tools  that  allow  for  guided 
navigation  of  artifacts  in  software  repositories.  These  tools  will  take  advantage  of  the  improved 
repository  framework  developed  during  the  previous  effort.  The  value  of  the  repository  tools  will 
be  demonstrated  through  use  case  demonstrations,  sponsor  evaluations,  and  a  focus  group 
study. 


The  results  will  be  detailed  requirements  specifications  for  user  tools  associated  with  the 
new  repository  framework,  including  specifications  for  both  the  repository  user  interface  tool  as 
well  as  the  asset-submission  tool.  The  repository  user  interface  tool  will  enable  multiple  views  of 
repository  contents  for  improved  search  efficiency.  The  tool  will  be  open-ended  to  allow 
extension  based  on  the  domain  knowledge  of  the  repository  manager  and  users.  The  asset- 
submission  tool  will  aid  software  developers  in  properly  describing  and  characterizing  items  as 
they  are  submitted  into  a  repository.  When  implemented  as  a  repository  system,  these  products 
will  enable  sophisticated  search  and  discovery  of  reusable  artifacts  and  maintenance  of  the 
repository,  which  will  improve  the  current  state-of-the-art. 


Summary 

Each  piece  of  the  repository  framework  enhances  the  search  capabilities  in  different 
ways.  The  basic  metadata  in  the  XML  schemas  provides  search  criteria  for  finding  components 
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of  interest  in  the  repository  as  well  as  specific  information  about  the  artifacts  in  order  to 
determine  if  they  are  appropriate  for  retrieval.  OWL  taxonomies  and  ontologies  enable 
identification  of  functionality  and  associated  resources  that  may  be  beneficial  to  users.  In  short: 


■  The  metadata  is  evaluated  to  enable  retrieval  decisions. 

■  The  software  behavior  representations  enable  searches  based  on 
functionality. 

■  The  ontologies  point  users  to  helpful  artifacts  they  may  not  have  initially 
considered. 

The  current  efforts  will  result  in  designs  for  repository  tools  that  will  take  full  advantage  of 
the  repository  framework  to  enable  guided  search  and  discover  as  well  as  asset  submission. 
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Program  Management 
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Goal  -  Improve  Current  Software 
Repository  Capabilities 


•  Types  of  searches  typically  supported  by 
repositories 

-  Keyword  search  over  metadata  -  dependent  upon 
semantic  assumptions 

-  Browsable  categories  -  becomes  ineffective  as 
size  grows 


•  The  goal  of  this  research  is  to  improve 
repository  utility  by  expanding  capabilities 

•  Initial  research  conducted  in  support  of  PEO 
IWS  for  the  SHARE  repository 
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Repository  Framework 


•  Developed  enriched  metadata  and  semantic 
descriptions  for  improved  search  and  reuse 

•  Goal  of  proposed  framework  is  to  enable 
multiple  search  and  discovery  options: 


-  Semantic  Search  (e.g.,  relationships) 

-  Model-Based  Search  (e.g.,  structures) 

-  Maintain  traditional  search  options  (e.g.,  keyword) 


•  Approach:  Repository  Framework 


-  Component  Specification 

-  Ontology 
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Component  Specification  and 
Ontology 


•  Component  Specification  -  a  description  or 
model  of  the  items  in  the  repository 

-  “Typical”  Metadata  -  information  about  an 
asset/artifact 

-  Software  Behavior  Description  -  a  searchable 
representation  of  the  software  asset’s  behavior 

•  Ontology  -  a  contextual  model  of  the 
repository  items  describing  their  relationships 
to  aid  in  associating  artifacts  with  user  needs 


Metadata 


•  “As-is”  Schema 

-  Reflects  current  metadata  schema  in  SHARE 

-  Align  with  data  entry  steps  in  SHARE’S  Asset 
Information  Form  wizard 


•  Recommended  “To-be”  Schema 


-  XML  Schema  designed  using  Artifacts  as  the 
basis 


-  Incorporates  software  behavior  and  ontology 
references 

•  Evaluated  both  schema  approaches  against 
other  metadata  schemes 
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As-is  Metadata  Schema 


Top  Level  Elements  correspond 
to  steps  2-12  of  the  SHARE 
data  entry  wizard. 


—  Programlnformation  [+] 

—  AssetDescription  ]+) 

—  AssetScope  [+] 

—  RelatedAssets  [+] 


SHAREAssetInformation  [^] — - DevelopmentStatus  [+] 


This  XML  Schema  describes 
(formation  entered  into  the 
Software  Hardware  Asset  Reuse 
Enterprise  (SHARE)  Asset 
Information  Form. 


Sourceldentification 


ion  [+] 


Contextlnformation 


1 


ArtifactsContained 


5 


—  CombatSystemsObjectiveArchit...|+l 

I 


—  DataFormat 


—  RightsAndRestrictions  [+] 

Generated  by  XMLSpy  www.altova.com 


efense  Acquisition  in  Transition 

£_H  Annual  Acquisition  Research  Symposium 


A  s  s  etDe  sc  ri  pti  onTy  pe 


Descriptive  information 
about  the  asset,  including  its 
type,  classification,  and 
rationale  for  submitting  the 
asset. 


—  Description 


AssetDescription  — -(  —  ^El~ 


AssetMame 


TypeAsset 


Version 


'Date 


Classificationlnformation 


1 


'  Rationale 


All  XML  Schema  developed 
using  Altova  XMLSpy. 


May  12-14,  2009 
Monterey,  CA 


To-be  Metadata  Schema 


Two  schemas  to  capture 
data  at  appropriate  level  of 
granularity 

Artifact  Schema  describes 
individual  artifacts  (smallest 
useful  package  of  items) 

Asset  Schema  defines 
package  of  artifacts  to  meet 
a  particular  need 

Allows  user-defined  assets 
as  well  as  submitter-defined 
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Asset  - 

Recommended  packaging  of 
artifacts  into  assets.  Assets 
are  defined  as  a  groufxng  of 
artifacts  which  provide  a 
solution  to  a  problem  for  a 
given  context.  Assets  can 
be  either  user  defined  based 
on  search  resuits  or  packages 
that  are  considered  common 
solutions  to  common 
problems.  This  defers 
significant^/  from  the  concept 
of  an  asset  as  currendy 
concaved  in  the  SHARE 
Repository'.  Type: 

AssetType 


AssetType 


—  ^Purpose 


—  "Initial  Use 


Qeh 


—  .AssetName 


r  identifier  of  an 
ype:  >5: string 


Purpose  for  the  Asset  (w! 
for).  Type:  xs:string 


Iracial  use  of  the  Asset. 
Type:  xsistring 


.  PreviousUses 


1 


use  or  previous  uses  or  u* 
Asset.  Type: 

Prev  ousUsesT  ype 


—  ^AssetScope 


Desoipti 


f  the  functional 


—  AssetCategory 


of  the  Asset.  Type 
A  ssetCategcryT yc 


e  category 


.Artifactslncluded 


Ust  of  Artifacts  irvek 
the  Asset.  Type: 


Asset  Schema 

1 


~  Retrievallnformation 

Information  on  how  to 
retrieve  the  Asset  content. 
Type:  xs:string 
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Software  Behavior  Representation 


•  Informal  Approach 

-  Common  System 
Function  List,  Web 
Service  Description 
Language 

•  Behavioral 
description  elements 
are  included  in  the 
metadata  for  each 
artifact 


efense  Acquisition  in  Transition 

£_H  ANNUAL  ACQUISITION  RESEARCH  SYMPOSIUM 


May  12-14,  2009 
Monterey,  CA 


Relationships  (Ontology) 


Multiple  sources  of  context 
for  repository  artifacts 

-  Artifact’s  place  in  the 
Software  Engineering 
Lifecycle 

-  Original  System  Architecture 
(Aegis,  SSDS,  etc.) 

-  Surface  Navy  Open 
Architecture  reference 
architecture 

-  Semantic  relationships 
(ReSEARCH  work) 

Ontologies  represented  in 
OWL-DL  (Description 
Logic) 
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Fish  Eye  Graph 

(Sarkarand  Brown,  1993) 
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Lifecycle-Artifact  Ontology 


•  Links  artifact 
development 

▼  0  LifecyclePhases 

0  ConceptDevelopmentActivity 
0  DeploymentActivity 
0  DesignActivity 
0  ImplementationActivity 
0  MaintenanceActivity 
9  RequirementsActivity 
TestingActivity 
T  ^  SoftwareArtifacts 

►  0  ArchitectureArtifacts 
▼  0  CodeArtifacts 


types  to 
activities 


•DesignArtifacts 

•TesArtlacts  |  ^  |  #0iiKrAmla«ts 


□ 


CompiledLibrary 


9  ExecutableProgram 
9  SourceCode 

►  9  DesignArtifacts 

►  9  InterfaceArtifacts 

►  9  OtherArtifacts 

►  9  RequirementsArtifacts 

►  9  SimulationArtifacts 

►  9  Test  Artifacts 

►  9  User  Artifacts 


rdfs:  comment 


•CodaArtfaets 

•  UserArtifacts 

Q - - 

•InterfaceArtifacts 

□ 


□ 


•SoftwareArtifacts 


I  Re  qui  rementsA  rtifacts 


/ 

/ 

•Requireme/itsPhase 


0?  % 


|  RequrerrvintsOatabase 


□ 


•RequirerrentsSpeciflcations 

□ 


)  Deploy mentPhase 

^ ^  •MamtenancePhase 

.  □ 

UfecyciePhas*'  •implerrontationPhase 

•DestgnPhase 
•TestngPhase  □ 

\  □ 

ConcectOevefoprrent 

□ 


\ 


9  CodeArtifacts 

0  oftenDevelopedDuring  some  ImplementationActivity 
0  oftenUsedDuring  some  TestingActivity 


Lifecycle-Artifacts 

Relationships 


PROPERTY  BROWSER 


For  Project:  •  Artifacts 

|  Object  j  Datatype  [  Annotation  |  All  | 

!■  Object  properties 


W 


i  oftenDevelopedDuring 


tiavPfoduce  Artifact 
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I  oftenUsedDuring  *->  mayRequireUseOf 
I  mayProduceArtifact  *-*  oftenDevelopedDuring 
I  mayRequireUseOf oftenUsedDuring 
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Original  System  Architecture 


Captures 

-  System-subsystem 
relationships 

-  Interfaces 

-  Any  other  desired 
architectural  relationships 

Report  includes  example  to 
show  possibilities 

From  Aegis  SV-1  available  in 
RDA  CHENG  Naval 
Architecture  Repository  System 
(NARS) 


>AegisBaseline7_i 


©Displays 

©APX-100  ^ 

□ 


•  GPS 

OK 


►  NAV&I 

>au 


iCOBLU  .  ,  •GCCS-M  :J'~ 

□  o  °  ' 

•  CDLMS 

»JTIDS_DTS 

°  "  ?  fj'. 

•SATCOMT  erminal 

□ 


/ 


□  receivesFrom 

□  sendsTo 


•use 

□ 


|AWS_FCS 

□ 


JJ 

>4— 

. - 


®  CIWS 

D 

•spy-id 

O  -J  #SM 

A-  iQ 

Ay 

•  MK41  VLS 


©essm 

□ 


®  SEWIP 

□ 


w  A 


•JTM  <1  #DDS 

°  *  ° 
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Surface  Combat  System  Top  Level 
Objective  Architecture 


•  Converted  architecture 


view  to  OWL 


d  SurfaceCombatSystemObjectiveArchitecture  Protege  3.2  (file:\ 


File  Edit  project  OvM.  Code  Tools  VWidow  ©  Jambalaya  Help 

QBE]  “t  ©  ffi  fca  id  <?  *  E3i§l@  <► 


iUhW.4Uli!li235E 


♦  Metadata  (ObjectiveArchitecture)  OWLCIasses  |  ■  Properties  j  ♦  Individuals  |  2  Forms  |  ©  Jambalaya 1  |  OWLViz  | 


^JnJxJ 

{\prot£g£ 


Ptatform  Adaptation 


External  C 
Domain 


Display 

Domain 


f53 


>r  Pi  oject:  #  SurtaceCombatSystemObiectiveArchitecture 

iss  Hierarchy  •  *  'r 

#  Platform_Adaptation 

•  Command_and_Control_Domain 

•  Common_Management_Software 

•  ASW_Trainer 

•  Combat_System_Trainer 
▼  K>  Command_and_Control_Domain 

•  C2_Support_Services 

•  Decision_Support 

•  Force_Warfare_Planning 

•  Intel 

•  Ship_Resource  Jvlanager 

•  Tactical_Decide_and_Assess 

•  Tactical_Mission_Planning 

•  Common_GUIs 

•  Comms_Domain_Manager 

•  Computer_Based_Training 

•  Damage_Control 

•  Display  _Framework_Support_Services 
>  Engineering  Control 


»j«* .  mm 


Iwi  a.-lasu|A|-aia  is  ft|:i  a  n 


•  P I  atfo  rm_A  d  a  ptati  on 


jn Marragernent Software' 


ft  Extern  al CommunicationsiDomain 


nnn 

□ 


n  n  h  n  n  n 
□□□□□□ 

□  □□ 

z!  CJ Command_and_Control_Domain  j  |  | 

□  □□□□□ 
□  □  □  a 

□ 

#lnfrastructure_Domain  •  S  en  so  r_M  a  n  ag  e  ment_D  oma  i  n  #Ship_Control_Domain 


□  □□□ 
□  □  □  □ 
□  □□□ 
□ 


□  □□□□ 

□  □  □  □  □ 
□  □  □  □  □ 

□  □  a  a  □ 

□  □  □ 


zinc 
□  □□ 
no 


non 

□  □□ 

•  Support_Domain 
□  □  □  □ 
□  □  □  □ 
□  □  □  □ 
□  □  □  □ 


#Track_Management_Domain  •Vehicle_Control_Domain  #Weapon_Management_Domain 


□□□ 

□□□ 

□□□ 

□  □no 

□  □□□ 
□  □ 

□□□□da 

□□naan 

□  □  □  □  a  □ 

□  □  □  □  □  □ 
nnn 
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Schema  References  to  Ontologies 


I  SoftwareBehaviorDescriptionType 


n 


Softwai  eBehavioi  Desci  iption 


A  description  of  the  behavior  of  the 
software  found  in  or  related  to  the  artifact. 
T ype :  SoftwareBehaviorOescriptionT y pe 


-[^CommonSystemFunctionList 

Functions  that  are  addressed  by  the 
artifact,  validated  against  the  ontology 
built  for  this  project  based  on  the  Navy's 
CSFL  found  in  separate  document, 
"CommonSystemFunclionList  .owl" .  T ype : 
CSFLType 


-I^WebServicesDescr iption  ; 

The  Web  Services  Description 
Language  (WSDl)  description  of  the 
software  found  in  or  related  to  the 
artifact.  Currently  a  placeholder 
until  better  defined  Type:  xs  string 


CSFLType 


<3H2 


CommonSystemFunction  ! 


CLco 

Individual  functions.  Currently 
expressed  as  an  optional  item  until 
the  information  can  be  input  for  all 
artifacts  in  SHARE.  Type:  xsistring 


|  ObjectiveArchitectureTags~j^h 

The  portion  of  the  Navy's  objective 
architecture  to  which  the  a  rtf  act 
appfces.  Type: 

ObjectiveArcfwectureT  agsType 


ObjectiveArchitectureTagsType 


n 


& 


-[^DomainTags 


|  DomainTagsType 

"~(~***~)El-~|^PomainTag  | 


objective  architecture  to 
which  the  artfact  appfes. 

=  -A:  -=: 

the  subclasses  of  the 
Platform  Adaptation  class  n 
the  objective  architecture 
ootoiog^'.  Type: 
DomamTagsType 


-jj,  SubDomainTags"^}- 


|  SubDomainTagsType 

L(~ )3~|;  SubPomainTag 


n 


The  subdomain  elements  in 
the  objective  architecture  to 
which  the  artifact  applies. 
Should  be  verified  against 
the  second  level  subclasses 
of  the  Platform  Adaptation 


1..CC 


Platform  Ad 
the  object  v 
ontology, 
SubDomain 


n  class  of 
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ArtifactType  [jj}- 


Artifact  type  and  subtypes 
are  dencched  as  attributes  cr 

ArtifactTypeValues 


ArtifactTypeValues 


□  attributes 

:,Type  ; 


Corresponds  to  the 
subclasses  of  the 
SoftwareArbfacts  dass  in  the 
artjfacts-fifecyde  ontology. 


^SubType  ; 

Corresponds  to  the  second 
level  of  subdasses  under  the 
SofrwareArbfacts  dass  in  the 
artifacts^fecyde  ontology. 


Recommended  metadata  schemas 
tie  artifacts  to  ontologies 


ApplicableSystemsType 


*  art -act  s  used. 

■  fTfitinnal  *ield  sir 
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User  Scenarios 


•  Requirements  Phase  Scenario 

-  Start  with  metadata  to  select  a  particular  item  of  interest 

-  Use  behavior  descriptions  (CSFL)  and  ontologies  to  expand 
list  of  useful  items 


•  Design  Phase  Scenario 

-  Start  with  CSFL  to  identify  group  of  items  of  interest 

-  Use  metadata  to  identify  items  that  should  be  retrieved. 

•  User’s  context  drives  search  and  discovery  process 
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Current  Research  Efforts 


•  Design  of  software  repository  tools  that  allow  for 
guided  navigation  and  insertion  of  artifacts  in 
repositories 

-  These  tools  will  take  advantage  of  the  improved  repository 
framework  developed  during  the  previous  effort. 

-  Demonstrate  the  value  of  these  tools  through  use  case 
demonstrations,  sponsor  evaluation,  and  a  focus  group 
study 


•  Detailed  Specification 

-  Search  and  Discovery  Tool 

-  Asset  Submission  Tool 
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Questions? 


Jean  Johnson 
Systems  Engineering  Dept. 
Naval  Postgraduate  School 

imiohnso@nps.edu 

(757)574-7563 
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